1. Technical Field
The disclosed technology relates to the field of controlling operations on computer accessible information within a scoped computing environment.
2. Background Art
An access control policy (ACP) is a set of policy statements of the form (“Subject”, “Privilege”, “Object”) defining the privileges that the subject has to act on the object. The set of policy statements can be very large and difficult to administrate. Many systems use a hierarchy of Subjects, Assigned Privileges, and Objects to more concisely specify the access control policy. It is common to use “Groups” to represent sets of Subjects, “Roles” to represent named sets of Assigned Privileges, and “Containers” to represent sets of Objects. Example containers include Workspace, Folder, Inbox, etc. Some systems model Role as a mapping of Subjects to Assigned Privileges, and therefore, use the Roles to represent a grouping of Subjects and Assigned Privileges. The following is an example access control policy formulated in this policy model:                1. ProductManagementGroup is a Group that contains a set of Subjects {Bob, Tom, John}        2. ProductManagementRole is a Role that contains named set of Privileges {Create, Assign, Delegate, Close}        3. DemoWorkspace is a Container holding a set of Objects {DocumentDemoTaskList, EmailDemoTaskList, CalendarDemoTaskList}        
The access control policy statement (ProductManagementGroup, ProductManagementRole, DemoWorkspace)is a concise statement that contains the policy statement tuples from the cross product of the three sets ({Bob, Tom, John}×{Create, Assign, Delegate, Close}, ×{DocumentDemoTaskList, EmailDemoTaskList, CalendarDemoTaskList}). Thus, there are 36 (3×4×3) policy statements defined by this access control policy statement.
Any of the Subjects Bob, Tom, and John can belong to more than one Group. A Privilege can be assigned through more than one Role. An Object can also belong in more than one Container. Thus, to determine whether a Subject has the Right to act on an Object, the authorization process of an access control model must evaluate policy statements from multiple Groups, Roles, and Containers.
An entity can be contained in a hierarchy of containers. The entity need not use explicitly specified Rights to the entity because often the Rights can be derived from the entity's container hierarchy (such as a workspace, an inbox, or a user folder). Examples of such a situation include message forward/reply chains and document hierarchies (including for example, document artifacts that are attached to message artifacts) as well as file systems or other hierarchical structures.
Many systems, especially collaboration systems, use the concept of the Scope that represents a managed environment to enforce the access control policy (and other policies for quota, template, and category) of the Scope in isolation from all other Scopes. A user can make persistent changes to the configurations (which include access control policies, other policies, sensitivities, quotas, templates, categories, etc.) and the scoped entities without interfering with the configurations and scoped entities in other Scopes. A Scope can be contained in a hierarchy of Scopes, but unlike the generic Containers, the Scope can belong in a single hierarchy of Scopes. Hence, there is no issue of multiply inheriting access control policies or any other type of policies for Scopes.
There are situations where it would be advantageous to evaluate whether a Subject has Rights to operate on an Object based on the Scope. To apply the Rights with respective to a Scope, one must follow a chain of client-supplier pairs from the supplier entity leading back to the Scope to consider the access control policy of each Container in the chain that grants or denies the subject's Rights to the entities in the Container. However, the number of access control policies can grow non-linearly because of combinatorial explosion in the enumeration of all chaining of client-supplier pairs to the supplier entity from the Scope when each of the access paths (chains) can introduce its own effective access control policy. In addition, the policy statements that must be evaluated increase non-linearly with increasing numbers of Objects, Subjects and Roles. This combinatorial explosion or non-linear growth problem has prohibited implementation of scope-centric access control models in any reasonably sized system. It would be advantageous to provide a scope-centric access control model that is not subject to the non-linear growth problem.